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Express Mail Label No. EL930547259US 

[0001] DETERMINING CONTROL OF AN 

INTERNET COMMUNICATION BETWEEN A SENDER AND A RECEIVER 

[0002] This application claims priority to U.S. Provisional Patent Application No. 

60/293,798, filed on May 25, 2001. 

[0003] BACKGROUND 

[0004] The present invention relates to communications between a user equipment 
(UE) and a network of a wireless communication system. More specifically, the present 
invention relates to resource reservation protocol (RSVP) signaling in such a system. 
[0005] RSVP signaling is used to make reservations for multimedia traffic originated 
or terminated in wireless systems. It is used to ensure the integrity and Quality of Service 
(QoS) for these services, especially in communications that are carried across external 
internet protocol (IP) networks. RSVP signaling can be originated by the UE and carried 
across the radio frequency (RF) interface toward the wireless network into an IP network, 
or it can be generated by the general packet radio service gateway support node (GGSN) 
which acts as RSVP proxy server on behalf of the UE. In the first case, the UE performance 
of RSVP signaling will consume a considerable portion of the air interface resources which 
can be avoided by implementing the Proxy operation in the GGSN. When the proxy 
function is performed by the GGSN, a negotiation mechanism is needed between the GGSN 
and the UE to ensure the proper operation and avoid any race conditions, where both entities 
simultaneously transmit RSVP signaling. A controlling module should be available to 
assign the RSVP signaling function, if necessary. This control module could reside in the 
GGSN or it can reside in the Policy control function (PCF). Lacking a clear assignment of 
RSVP responsibility may result in either a race condition, where both entities transmit 
simultaneously, or lack of any transmission of RSVP path and refresh messages to update 
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the reservation state in routers along the reservation path. This lack of refreshment messages 
will result in the expiration of the reservation states and loss of allocated resources. 

[0006] SUMMARY 

[0007] The present invention addresses the possibility of a race condition that arises 
due to lack of a communication mechanism between the UE and the GGSN, saving 
unnecessary consumption of radio resources and reducing chances of collisions within the 
network. Also, the invention prevents the possibility that neither the UE nor GGSN respond 
appropriately to the Resource Reservation Protocol (RSVP) requirements by halting 
transmission of any RSVP path/refreshment messages to the IP network in order to 
refresh/maintain the reservation states due lack of clear assignment of responsibility. This 
lack of clear understanding between the UE and the GGSN may result in the expiration of 
the IP network resource reservations made earlier for media streams. This scenario can 
occur with a higher probability in the absence of this dialog. 

[0008] BRIEF DESCRIPTION OF THE DRAWING(S) 

[0009] Figure 1 is an example of an RSVP signaling mechanism. 

[0010] Figure 2 is a simplified diagram of a wireless network. 

[0011] Figures 3 and 4 are flow charts illustrating the GGSN assigning the RSVP 

proxy function. 

[0012] Figures 5 and 6 are flow charts illustrating the PCF assigning the RSVP proxy 
function. 

[0013] Figures 7 through 14 are flow charts illustrating preferred signaling scenarios. 

[0014] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S) 
[0015] Figure 1 shows a system 10 utilizing a RSVP basic operation (illustrated for 
simplicity in a wired environment). One user (sender 12) initiates a multimedia session with 
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a second user (i.e., receiver 14) and tries to reserve the resources to establish the session, 
although other subscribers to the system (S1-S4) are shown. The example given here is 
limited to subscribers 12, 14 for purposes of simplicity. The RSVP protocol is used to go 
through the specified route of the requested session and make a reservation to ensure the 
quality of service (QoS) necessary to carry the session. The RSVP Sender 12 transmits a 
PATH message (see path 1, 2, 3, 4 and 5) through a RSVP router 16, non-RSVP router 18, 
RSVP tunnel 19, non-RSVP router 20 and RSVP router 22 to allocate the resources along 
the routing path and store the media attributes necessary for the session. The Receiver end 
14 acknowledges the PATH message with a reservation (RESV) message to establish the 
resources (see path 6, 7, 8, 9 and 10). The RESV message is sent through RSVP router 22, 
non-RSVP router 20, RSVP tunnel 19, non-RSVP router 18 and RSVP router 16. Once the 
RESV message is received at sender 12, a final acknowledgment (not shown) is sent back 
to the receiver 14 using the same path. After receipt of the final acknowledgment, both sides 
start the session. Periodically, the Sender and the receiver sides will refresh the resource 
reservation along the routing path through RSVP refresh messages. Otherwise, the 
reservation state in routers across the path will expire and resources will be re-allocated. 
[0016] For a wireless network, the user equipments 3 1 or users are connected to the 
multimedia/IP network 33 through a wireless network as shown in Figure 2. Figure 2 shows 
the essential parts of a wireless network, such as a universal mobile terrestrial system 
(UMTS) network 30, that are involved in the RSVP operations. As shown, the Call Server 
Control Function (CSCF) policy control function (PCF) 32 acts as the policy control point 
where decisions are made regarding the user services, the handling of media streams and 
QoS resource issues. The GGSN 34 represents the gateway function, which potentially acts 
as the RSVP Send/Receive proxy. Also, the GGSN 34 contains all the mobile profile 
information packet data protocol (PDP) context, and has the resources necessary to carry 
both signaling and traffic information. The GGSN 34 acts as the controlling authority for 
all mobile activities. It assigns the IP address and decides, with the serving GPRS support 
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node (SGSN) 36, the potential modes of operation. The RSVP signaling is transparent to 
both the UMTS terrestrial radio access network (UTRAN) 38 and SGSN 36. The decision 
point and the associated control logic on the manner and location of handing the RSVP 
signaling is preferably located at either the CSCF (PCF) 34 in association with the overall 
QoS policy control or at the GGSN 34 with other resource control functions. In an 
alternative embodiment, a dynamic allocation of responsibility of the RSVP signaling to the 
CSCF (PCF) 34 and CGSN 34 is provided since the GGSN 34 is in control of most of the 
network resources and can detect (or determine) a situation where the wireless network is 
congested and use this mechanism to alleviate some of the excess traffic. 
[0017] In one embodiment, the GGSN 34 decides whether it or the UE 31 will 
perform the RSVP function. To prevent a race condition, multiple or no transmissions, the 
GGSN 34 interacts with the UE and clearly assigns the responsibilities for RSVP signaling. 
The decision may be made statically or dynamically. If the decision is made statically, the 
decision is made only at the time of initiation. If the decision is made dynamically, the 
GGSN 34 may change who performs the RSVP function at any time. This decision is 
typically based on local traffic conditions, such as the availability of air link resources versus 
the availability of network resources, and local policy. To illustrate, if air link resources are 
scarce, the GGSN 34 may decide to switch the RSVP function from some UEs to itself. By 
contrast, if the GGSN's resources are being highly utilized, it may shift the RSVP function 
to some of the UEs. 

[001 8] A flow chart indicating a preferred procedure for the GGSN 34 to assign the 
RSVP function to the UE 31 is illustrated in Figure 3. After the GGSN 34 determines that 
the UE 3 1 will perform the RSVP function, it sends the UE 3 1 a message indicating that the 
UE 31 controls the RSVP function via the wireless network, step Al. After the UE 31 
receives that message, it sends an acknowledgment message (ACK) to the GGSN 34, step 
A2. To reserve a path to the destination user, the UE 3 1 sends a reservation path message 
(PATH message) to the external network 33 through the wireless network 30, step A3. 
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After the external network 33 receives the PATH message, it reserves those resources for 
the UE 31 and sends the UE 31 back through the wireless network 30 a RSVP reservation 
message, step A4. After the UE 31 receives the RSVP reservation message, it sends an 
activate/modified secondary PDP context message to the SGSN 36 via the UTRAN 38, step 
A5. After receiving that message, the SGSN 36 sends a context request message through 
the GGSN 34, step A6. In response to receiving the context request message, the GGSN 34 
sends a RSVP reservation (RESV) confirmation message to the external network 33 and a 
context response message to the SGSN 36, step A7. After the SGSN receives the context 
response message, it sends an activate/modify secondary PDP context accept message to the 
UE 31, step A8. After the UE receives the acceptance message, it carries on the proxy 
function, step A9. 

[0019] To maintain the path throughout the external network 33, the UE 31 must 
periodically send a refresh path message through the external network 33. The refreshing 
prevents components of the external network 33 from timing out and releasing the resources. 
After the external network 33 receives the refresh path message, it maintains its reservation 
of the path and sends the UE 31 a refresh reservation message indicating that the path will 
be maintained. 

[0020] In an alternate embodiment, although the GGSN 34 makes the proxy function 
assignment, the UE 31 may accept or reject the assignment. This procedure allows for 
negotiation between the UE 3 1 and GGSN 34. After receiving the message from the GGSN 
34 indicating that the UE 31 should perform the RSVP function, the UE 31 responds by 
accepting or rejecting, such as by an acknowledgment (ACK) or negative acknowledgment 
(NAK). If the UE 31 rejects the assignment, the UE 31 does not originate any RSVP 
messages and the GGSN 34 performs the function. 

[0021] A flow chart indicating a preferred procedure for the GGSN 34 to assign the 
RSVP function to itself is illustrated in Figure 4. After the GGSN 34 determines that it will 
perform the proxy function, it sends the UE 3 1 a message indicating that the GGSN 34 will 
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control the RSVP function via the wireless network 30, step B 1 . After the UE 3 1 receives 
that message, it sends an acknowledgment message to the GGSN 34, step B2. To reserve 
a path through the external network 33, the GGSN 34 sends a PATH message to the external 
network 33, step B3. After the external network 33 receives the PATH message, it reserves 
path resources and sends the GGSN 34 back through the wireless network 30 a RSVP 
reservation message, step B4. After the GGSN 34 receives the RSVP reservation message, 
it sends a RSVP reservation confirmation message to the external network 33. At the same 
time, it sends a modified secondary PDP context message to the SGSN 36, step B5. After 
the SGSN 36 receives that message, it sends a create/modify secondary PDP context 
message to the UE 31 via the UTRAN 38, step B6. In response to receiving the message, 
the UE 31 sends an activate/modify secondary PDP context message to the SGSN 36 and 
GGSN 34, steps B7 and B8. After receiving that message, the GGSN 34 sends an 
activate/modify secondary PDP context accept message to the UE 31 and carries on the 
RSVP function, steps B9 and BIO. To maintain the path through the external network, the 
GGSN 34 periodically sends a refresh path message through the external network 33. 
[0022] In another embodiment, the PCF 32 decides whether the GGSN 34 or the UE 
31 will perform the RSVP function. This decision may also be made statically or 
dynamically. If the decision is made statically, the decision is made at the time of initiation. 
If the decision is made dynamically, the PCF 32 may change who performs the RSVP 
function at any time. Alternately, the PCF 32 may delegate the decision to the GGSN 34. 
After the PCF 32 sends a delegation message to the GGSN 34, the GGSN 34 decides who 
performs the RSVP function. 

[0023] A flow chart indicating a preferred procedure for the PCF 32 to assign the 
RSVP function to the UE 3 1 is illustrated in Figure 5 . After the PCF 32 determines that the 
UE 3 1 will perform the RSVP function, it sends the GGSN 34 a message indicating that the 
UE 3 1 controls the RSVP function, step C 1 . The GGSN 34 forwards the message to the UE 
3 1 via the wireless network 33, step C2, and optionally acknowledges receipt of the message 
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by sending an acknowledgment (ACK) to the PCF 32, step C3. After the UE 31 receives 
the forwarded message, it also sends an ACK to the PCF 32, step C4. Alternately, the 
GGSN 34 does not send an ACK. The PCF 32 treats the ACK from the UE 31 as 
acknowledging receipt from both the UE 31 and GGSN 34. 

[0024] The UE 3 1 also sends a PATH message to the external network 33, step C6. 
After the external network 33 receives the PATH message, it reserves those resources for 
the UE 3 1 and sends the UE 3 1 back through the wireless network 30 an RS VP reservation 
message, step C6. After the UE 31 receives the RSVP reservation message, it sends an 
activate/modify secondary PDP context message to the SGSN 36 via the UTRAN 38, step 
CI. In response to receiving that message, the SGSN 36 sends a context request message 
to the GGSN 34, step C8. Subsequently, the GGSN 34 sends an RSVP space reservation 
confirmation message to the external network 33 and a context response message to the 
SGSN 36, step C9. After the SGSN 36 receives a context response message, it sends an 
activate/modify secondary PDP context accept message to the UE 31 via the UTRAN 38, 
step CIO. At that point, the UE 31 carries on the RSVP function, step CI 1. Periodically, 
the UE 31 sends refresh messages to the external network 33 to maintain the path through 
the external network 33. 

[0025] A flow chart indicating a preferred procedure for the PCF 32 to assign the 
RSVP function to the GGSN 34 is illustrated in Figure 6. After the PCF 32 determines that 
the GGSN 34 will perform the RSVP function, it sends the GGSN 34 a message indicating 
that the GGSN 34 controls the RSVP function, step Dl . After the GGSN 34 receives that 
message, it sends a message via the SGSN 36 and the UTRAN 38 to the UE 31 indicating 
that the UE 31 should not perform the RSVP function, step D2. Optionally, the GGSN 34 
also acknowledges receipt of the control message by sending an ACK to the PCF 32, step 
D3. After the UE 31 receives the message, it also sends an ACK to the PCF 32, step D4. 
Alternately, the GGSN 34 does not send an ACK. The PCF 32 treats the ACK from the UE 
31 as acknowledging receipt from both the UE 31 and GGSN 34. 
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[0026] To reserve a path through the external network 33, the GGSN 34 sends a 

PATH message to the external network 33, step D5. After the external network receives the 
PATH message, it reserves PATH resources and sends the GGSN 34 an RSVP reservation 
message, step D6. In response to the GGSN 34 receiving the RSVP message, it sends an 
RSVP reservation confirmation message to the external network 33. Simultaneously, it 
sends a modified secondary PDP context message to the SGSN 36, step D7 . After receiving 
that message, the SGSN 36 sends a create/modify secondary PDP context message to the UE 
31 via the UTRAN 38, step D8. After receiving that message, the UE 31 sends an 
activate/modify secondary PDP context message to the GGSN 34, step D9. In response to 
receiving that message, the GGSN 34 sends an activate/modify secondary PDP context 
accept message to the UE 3 1 and the GGSN 34 carries on the RSVP function, steps D 1 0 and 
Dll. To maintain the path throughout the external network, the GGSN 34 periodically 
sends a refresh path message through the external network 33. 

[0027] In another embodiment, the UE 3 1 and GGSN 34 negotiate responsibility for 
the RSVP signaling, for how long, and under what circumstances the responsibilities can 
shift. Either the UE 31 or GGSN 34 may initiate the negotiations. 
[0028] In another embodiment, the PCF 32 is used in conjunction with the UE policy 
enforcement so that the PCF 32 assigns the responsibilities to either the UE 3 1 or the GGSN 
34. The PCF in this case sends two orders: one to the GGSN 34 and the second to the UE 
31. This prevents a race condition or no transmission from occurring. The wireless 
network may also be hard coded to only allow either the GGSN 34 or UE 3 1 to perform the 
proxy function. The decision is communicated to the UE 31 during the PDP context 
activation process. 

[0029] Figures 7-14 illustrate some preferred signaling procedures between the UE 
31, UTRAN 38, SGSN 36, GGSN 34, PCF 32 and external network 33 for differing 
signaling scenarios. 
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[0030] Figure 7 illustrates one preferred signaling arrangement for PCF control of 
RSVP signaling. In Figures 7 and 8, the PCF 32 assigns control to the GGSN 34. The steps 
start at the top line of the figure and subsequent steps in time are represented at succeedingly 
lower positions beneath the top line. The direction of signaling is depicted by an arrow. 
[003 1] Initially, the proxy call service control function (PCSCF)/PCF 32 signals the 
GGSN 34 to act as the RSVP SEND/RECEIVE proxy, step El. The GGSN 34 
acknowledges, sending an ACK to the PCF 32, step E2. The PCF 32, step E3, 
communicates to the GGSN 34 that the UE 31 shall not use RSVP signaling. The GGSN 
34, step E4, communicates this message to the SGSN 36. The SGSN 36, step E5, 
communicates this message to the UE 3 1 . The UE 3 1 acknowledges this responsibility and, 
step E6, communicates an ACK to the SGSN 36. The SGSN 36, step E7, communicates the 
ACK to the GGSN 34. The GGSN 34, step E8, communicates the ACK to the PCF 32. 
[0032] In Figure 8, the PCF 32, at step Fl, communicates to the GGSN 34 that the 
GGSN 34 shall act as the RSVP SEND/RECEIVE proxy and the UE 31 should be silent. 
The GGSN 34 initiates an RSVP SEND/RECEIVE proxy for the UE 3 1 and informs the UE 
31 to be silent, step F2. This is communicated to the SGSN 36, step F3, which, step F4, 
communicates it to the UE 3 1 . 

[0033] The UE 3 1 , at step F5, sends an acknowledgment to the SGSN 36. The SGSN 
36, step F6, communicates the acknowledgment to the GGSN 34 which, in turn, transmits 
the acknowledgment, step F7, to the PCF 32. The UE 3 1 does not send any RSVP messages 
until further notice. 

[0034] Figures 9 and 10 illustrate various signaling scenarios for the GGSN 34 
deciding the responsibility for the RSVP proxy function. In Figure 9, the GGSN 34 decides 
it will assume the RSVP proxy function. The UE 3 1 , at step Gl , transmits an RSVP PATH 
to the GGSN 34. The GGSN, step G2, initiates a path through the External Network 33 
using a RSVP PATH message. The GGSN 34, step G3, upon receipt of the RSVP PATH 
from the UE 31, initializes the PROXY operation and informs the UE 31 to stop using a 
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STOP RSVP message, step G4. The UE 31 sends an acknowledgment to the GGSN 34 
through the UTRAN 38 and SGSN 36, step G5. The UE 31 does not initiate any RSVP 
messages until further notice from GGSN 34. After the GGSN 34 receives a RSVP RES V 
message from the external network 33, the GGSN 34 sends a Modify Secondary PDP 
Context message to the SGSN, step G7. The SGSN 36 sends that message to the UE 31, 
step G8. After the UE 3 1 receives the Modify Secondary PDP Context message, it sends an 
Activate/Modify Secondary PDP message to the SGSN 36, step G9. The SGSN 36 forwards 
that message to the GGSN 34, step G 1 0. To maintain the path through the external network, 
the GGSN 34, periodically transmits a Refresh PATH message, step Gl 1, and receives a 
Refresh RESV message, step G12. 

[0035] In Figure 1 0, the GGSN 34 decides to support the RSVP proxy function, after 
negotiation with the UE 31. The UE 31, step HI, transmits a message to the GGSN 34 
indicating that it should act as proxy for RSVP signaling. The GGSN 34, which decides to 
support the Proxy operation, step H2, initializes the PROXY operation and informs the UE 
3 1 to stop transmission, step H3 . This decision is incorporated in an acknowledgment to the 
UE 31. The UE 31 accepts the GGSN order and stops sending RSVP messages. 
[0036] The UE 3 1 initiates the session and, step H4, creates a secondary PDP context 
message which is transmitted to the GGSN 34 via the UTRAN 38 and SGSN 36, steps H5 
and H6. The GGSN 34, step H7, modifies the secondary PDP context message and accepts 
the UE' s communication and transmits the acceptance to the UE 3 1 , through the same path, 
steps H8 and H9. The GGSN 34, step H10, transmits an RSVP PATH message to the 
external network 33 and receives a RSVP RESV in reply, step HI 1. The GGSN 34, step 
H12, confirms receipt of the RSVP RESV by sending a RSVP RESV confirmation. To 
maintain the path, the GGSN 34 periodically sends a Refresh PATH message, step HI 3, 
and, in turn, receives a Refresh RESV message, step H14. 

[0037] The UE 3 1 and GGSN 34 may engage in a negotiation as to who shall take the 
responsibility for RSVP signaling, for how long and under what circumstances the 
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responsibilities can shift. In Figure 1 1 , the UE 3 1 , at step 1 1 , requests that the GGSN 34 acts 
as proxy for RSVP Signaling. The GGSN 34, step 12, decides that it will not support the 
PROXY operation and, step 13, informs the UE 3 1 to resume responsibility by transmitting 
a NAK. The UE 31, step 14, transmits an RSVP PATH message to the GGSN 34. The 
RSVP PATH message is transmitted to the receiving UE, step 15, through the External 
Network 33. The receiving UE transmits an RSVP RES V through the External Network 33 
to the GGSN 34, step 16. In turn, the GGSN 34 transmits the RSVP RESV to the UE 31, 
step 17 and a RSVP RESV confirmation message to the external network, step 110. The UE 
31, step 18, transmits an Activate/Modify secondary PDP Context to the SGSN 36. The 
SGSN 36, step 19 transmits a Context request to the GGSN 34. At step II 1, the GGSN 34 
transmits a Context Response to the SGSN 36 which sends an Activate/Modify Secondary 
PDP Context Accept message, step 112, to the UE 31. The UE 31, to maintain the path, 
transmits, step II 3, a refresh message, which is communicated to the GGSN 34. This refresh 
path message is transmitted by the GGSN 34, step 114, to the External Network 33. The 
External Network 33, responds to the GGSN 34 with a Refresh RSVP, stepI15. The GGSN 
34, step 116, transmits this message to the UE 31. 

[0038] The GGSN 34 may also send messages to the UE 3 1 indicating that the GGSN 
34 recommends that either the UE 3 1 or GGSN 34 perform the RSVP function. The UE 3 1 
may either accept or decline the recommendation. Typically, the final determination of who 
performs the RSVP function, if negotiation is unsuccessful, is left to the GGSN 34. 
[0039] In Figure 12, the GGSN 34 decides to support the proxy operation. The 
External Network 33, step Jl, transmits an RSVP PATH message to the GGSN 34 from a 
UE in the External Network 33. The GGSN 34, step J2, decides to support the proxy 
operation and informs the UE 31 not to send RSVP signaling. The GGSN 34, step J3 
transmits a Create/Modify PDP Context to the SGSN 36 which, step J4, transmits this 
message to the UE 31. The UE 31 receives this message and, step J5, transmits an 
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Activate/Modify Secondary PDP Context to the SGSN 36. The SGSN 36, step J6, transmits 
this message to the GGSN 34. 

[0040] The GGSN 34, step J7, transmits an Activate/Modify Secondary PDP Context 
Accept to the SGSN 36, which, step J8, transmits this message to the UE 31. In addition, 
the GGSN 34, step J9, transmits an RSVP RESV to the External Network 33 which 
responds with an RSVP RESV Confirmation, step Jl 0. The UE associated with the External 
Network 33, step Jll, transmits, through the External Network 33 to the GGSN 34, a 
Refresh Path Request message. The GGSN 34 responds by sending a Refresh RESV 
message, step J12. 

[0041] In Figure 13, the PCF 32 makes the RSVP function decisions. The UE 3 1, 
step Kl, sends a request that the GGSN 34 should act as RSVP PROXY to the PCF 32. 
This message is handled by the PCF 32 which, step K2 makes a decision and, step K3 
advises the GGSN 34 that it is assigned the responsibility for the RSVP proxy. The PCF 32, 
step K4, further advises the UE 3 1 that it should stop sending RSVP messages. The GGSN 
34, step K5, acknowledges its assignment to the PCF 32 and the UE 31, step K6, also 
acknowledges that it will stop sending RSVP messages. 

[0042] Figure 14 is an arrangement similar to Figure 13 except that the GGSN 34 
sends a request to the PCF 32 that the UE 31 should act as the RSVP proxy, step LI . The 
PCF 32, step L2, makes a decision and assigns the RSVP proxy assignment to the UE 31, 
step L3. The PCF 32 further instructs the GGSN 34 that it not act as RSVP proxy, step L4. 
The UE 31 acknowledges its assignment, step L5, and the GGSN 34 acknowledges its 
assignment, step L6. 

[0043] It should be understood that the PCF can make the reverse decisions to those 
shown in Figures 1 3 and 14. For example, considering Figure 1 3, when the UE 3 1 requests 
that the GGSN 34 should act as RSVP, the PCF 32 may decide that the UE 3 1 should act as 
RSVP proxy anyway. In a similar fashion, making to reference to Figure 14, the PCF 32 in 
response to a request from the GGSN 34, that the UE 3 1 should act as RSVP PROXY, may 
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decide that the GGSN 34 act as the RSVP proxy anyway. Since, in Figures 13 and 14, the 
PCF 32 sends an order to both the UE 3 land GGSN 34, it is unlikely that a race condition 
or no transmission at all will occur. 

[0044] To assure that no RSVP signaling occurs during static set up (initialization), 
a control mechanism is preferably used that instructs the UE 3 1 not to send RSVP signaling 
messages while allocating the responsibility to the GGSN 34 or alternatively, the control 
mechanism instructs the GGSN 34 not to send RSVP signaling messages while allocating 
the responsibility to the UE 3 1 . 
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